The laboratory portion of software engineering is intended to provide each of you with the opportunity to development a solution for a problem. This activity involves working in a group, as a team, for the entire semester on one problem. Typically the problem has customer as the initial stakeholder. This individual has a situation they believe software or a software system would solve. The team's task is to determine what the problem is, propose a solution, then create the solution. Clearly one of the main obstacles is the fifteen week semester time-frame.
The lab for software engineering provides the time and place for groups of students to work on a software project. Being in a group is required, and participating in the group's activities is required. Groups consist of six people. The first task is to form groups. Once groups are formed a group will meet with the instructor to determine the project they will work on. Each group will have a customer. The group or its representatives will meet with the customer to determine the initial set of requirements. Involvement of the customer is dependent on the needs of the group and the desire of the customer.
As mentioned earlier, the group consists of six people. Since part of the learning involved in software engineering is best practice, I have decided to use a CMM Level 2 model for each project. This model requires certain practices to be used and designated individuals to be charge with insuring the tasks associated with these activities are carried out correctly. Hence, each team will have an individual that fulfills each of the following roles with its associated responsibilities:
Each group will have a project manager. This individual is committed to managing the daily functions of the group and communicating with the customer and instructor. A major task for the project manager is defining and documenting the development process to facilitate project planning and project tracking. Project management requires a model for how the team is expected to perform specific tasks. To facilitate project management functions, there is a document which describes the expectations for the person performing that role.
Each group will have a plan tracker. This individual is committed to tracking the daily functions of the group and communicating with the project manager and instructor. The daily management of the project requires the project manager have information which provides an indication of how the team in doing in accomplishing tasks, which tasks were accomplished, and how successful the various participants are on these tasks. To facilitate these project tracking and oversight functions, there is a document which describes the expectations for the person performing that role.
One of the difficulties each team faces is coping with the documents produced during the semester. One of the issues that must be addressed in what is current and how to integrate changes, successfully, into these documents. To encourage a deliberate approach to this task, each team will have an individual whose responsibility is to coordinate and manage the material developed by the group. The configuration manager has a number of tasks to perform during the course of the development activity. These tasks are documented for review.
One of the most demanding tasks in a development activity is determining what the problem is and detailing what a solution must "look" like. This is sometimes referred to as requirements analysis or requirements engineering. One member of each team is charged with the responsibility of dealing with determining and specifying the requirements. Since requirements are likely to change throughout the development activity, this person must have a detailed set of responses to potential threats to the stability of the requirements. Hence, requirements management is a position that exists throughout the development activity. The guidelines for the conduct of these activities is documented.
Quality very important. Dealing effectively with quality means starting early in the development activity, and instituting processes that encourage the development of a quality product. This means providing ample opportunities to review and inspect work products to determine they meet the project standards. But of course this implies the existence of such standards. Hence the SQA person, each team will have one, is responsible for the conduct of those activities that seem essential in increasing the probability that you produce a quality product.
Unlike the development activities in your early courses, the project in software engineering requires a more deliberate approach. This is true for several reasons: 1) there are more people's time to coordinate, 2) there are more tasks to apportion, and 3) there are risk at every turn. One team member will assume the tasks associated with project planning. This involves two, not one, plans. There should be a long-term (semester or project) and short-term (weekly/daily). This is a very involved activity requiring the individual to decompose large tasks into manageable subtasks then work out an arrangement whereby a team member tasks the responsibility of completing it. There are guidelines for developing both types of plans in the accompanying documentation.
Two individuals will be selected as project managers. Having a project manager does not imply a hierarchical team structure however. The project manager has the set of responsibilities defined in the accompanying document for that role. Furthermore it is the project manager that links to the instructor for planning of reviews and discussions. Manager is probably the wrong term but it is the one we are using. The teams will be formed through a process where the managers justify their staffing needs and match those needs to the qualities of the class members.
Attendance for each lab meeting is required. During the lab sessions groups can meet. During lab sessions group members can explore and/or learn to use the applications/tools on the machines in the lab (or elsewhere for that matter). Reviews are held during lab hours. Meetings with the instructor regarding project progress are held during lab hours. The instructor reserves the right to review the status of any project at any time. All documents should be available during lab time (this is especially true of the group diary).
Two major problems typically encountered in software engineering are 1) procrastination and 2) poor group organization.
The first problem manifests itself in the form of late work. If the group cannot meet the deadline as specified in the timetable established by the group through planning, then a formal request for an extension must be submitted to the instructor prior to the due date.
The second problem relates to group's inability to distribute tasks reasonably to members of the group. The instructor expects each group member to participate fully in all aspects of the project. The project tracking in combination with the planning documents should detail how the tasks are distributed, the deadline for completion for each group member, and the effort expended on a particular task. Note that distributed activity requires some time allocated to merging individual efforts.
One view of the project in software engineering is that it provides you the opportunity to solve a real problem for a real customer. That is true, but the real learning has to do with planning, task decomposition and working together. Those are the skills employers are looking for. When students go to interviews prospective employers ask about working as a member of a team. They are interested in your ability in that area. Very rarely do they discuss the type of problem or the nature of the solution. They are interested in the process skills.
Typically for this class you have a number of documents to produce. Over the years I have specified those directly. In the syllabus I indicate there are four documents required for this course.
Under the current model that is a difficult requirement. You should note that each team member has to produce a document as part of their role. This is either a plan for development or a plan for SQA. In all cases each person has an independent document. Also, each project begins with the assignment of a problem given as a statement-of-work, this replaces the product definition of early days. This leaves three documents outstanding. I will keep the legacy since that provides a way to conduct a postmortem on the project. That leaves two documents. The issue with documents has been a way to define milestones and deliverables for assessing progress. Unfortunately not all projects fit this mold. I will allow each project team to define deliverables as part of their development process.
Hence, each project team will produce
As indicated on the grading summary in your course information, each person should participate in reviews of another team's deliverables. It is the responsibility of SQA to plan, schedule, and recruit for reviews. One of those reviews should be of the requirements document. We have a reasonable start or a requirements review process. This can be adapted to meet your needs.