Team Roles

Roles	Members	Description
Manager	Gabe	The project manager is chiefly responsible for the project schedule (and, in an industrial setting, the budget). The manager does not need to be the "boss", though in industry it often works that way. The key thing the manager needs to be paying attention to, throughout the project, is the project plan and how actual progress compares to the plan.
System Architect	Frank	The system architect is responsible for understanding the overall structure of the software system: How it is divided into parts, and how the parts fit together. A good, modular system design allows most developers to think just about their own part, most of the time. The architect is constantly keeping an eye on the bigger picture of how things fit together. If the project manager and system architect are different people, then they will need to communicate regularly. In a sense, the manager is always looking at how pieces of the development process fit together, and the system architect is always looking at how pieces of the software system fit together, and any disruption in one is certain to affect the other.
Requirements Analyst	Aaron	The requirements analyst is responsible for understanding and communicating the system requirements. The system requirements define, as precisely as possible, the functional behaviour and qualities (e.g., performance, ease of use, etc.) that a system must have. The requirements analyst is responsible for identifying the system stakeholders, eliciting requirements, establishing priorities among requirements, and documenting them in a way that is access able to the key stakeholders. Note that this does not mean that the analyst makes the decisions about what should be requirements and their relative priorities, rather he/she determines these in collaboration with the stakeholders including other team members.
Quality Control	Hannah Belinda	Someone needs to be making sure, all through the project, that quality goals are likely to be met. This might include producing a good integration and test plan and making sure it is executed, managing design and code inspections during development, requiring good unit test suites with each module, etc. The role of quality control is a good illustration of the difference between taking responsibility for some important aspect of system development and doing all the work associated with that aspect. For example, suppose the quality plan includes insisting that each newly developed or modified module be accompanied by a good unit test suite. That doesn't mean the person primarily responsible for quality control writes all the unit test cases or even inspects them. It is more likely to mean that they establish (in consultation with the team) standard practices and expectations for producing and reviewing unit test suites.
Technical Documentation	Gabe	Technical documentation is documentation written for developers and maintainers of a system, rather than documentation written for users of the system. This may include everything from formal requirements and design documents to README files and comments in program code. As with quality control, the person who takes primary responsibility for technical documentation is not likely to do all the work him- or herself. The responsibility is for making sure it gets done well and on time, probably by coordinating the work of several people.
User Documentation	Frank	User documentation is documentation for users of a software system. Often it involves more than one group of users. For example, if one were producing a web-based application, both end-users of the system (using the service through a web browser) and administrators of the system (configuring and running the service on a web server) would be users, and they would require quite different documentation. User documentation may include conventional user manuals, online help, web-based documents and FAQs, and perhaps other forms of information.
User Interface	Ahmed Belinda	Ideally, a software project would have access to usability experts in a usability lab. Often, we don't, but it's still worthwhile to have someone take special responsibility for consideration of interface issues. Decisions in other areas often have usability and user interface consequences that are easily overlooked; the UI master is responsible for making sure they aren't overlooked.
Programmer	Aaron Frank	The programmer is, as the saying goes "where the rubber meets the road." The programmer is responsible for turning the need for system capabilities into something a computer with actually run. It should be clear, however, from the other roles, that the programmer cannot act independently. Rather he/she is responsible for realizing, as closely as possible, the requirements and designs developed by the team. This helps ensure that what the programmer produces is what the stakeholders want.
Configuration Control (Build-master)	Gabe	When several people are building and modifying parts of a software system, it helps to have someone in charge of keeping the changes coordinated and making sure the build process continues to work. As with other roles, part of the build-master's job is to establish practices for others, and part is to administer the version and configuration system. In large, complex projects, version and configuration control can be a huge issue, requiring a "configuration board" made up of individuals working on different parts of the system. For a CIS 422/522 project, it is much more manageable, but you will find that coordinating changes still becomes a challenge as deadlines approach.