The work-reflection-learning cycle - Department of Computer and ...

own account of why each artifact is of importance to one or more of the stakeholders.
Theis account should be based on communication with the project stakeholders.
The set of connections between artifacts and goals is in itself a boundary object,
typically manifest in documents such as a team/customer collaboration agreement and a
Software Development Plan, and typically developing throughout the project.
5.2. Implications for the pedagogical design of customer-driven SE project courses
Building on the previous discussion, we suggest that the following guidelines be
followed in the design of customer-driven project courses:
Stakeholders should be encouraged to make their goals explicit to themselves and
each other. Students should be aided in eliciting customer requirements. Also, they
should be encouraged to discuss team members’ objectives for project participation as
well as the goals for the team as a whole. Developing a set of team-internal project
rules may be useful. Course staff needs to make sure that learning goals and evaluation
criteria are clearly defined and easily available to students and project customers.
Course staff should also check on students’ understanding of the goals. Customers need
guidance about their role and about conveying their objectives as clearly as possible to
the group: ‘learning to be a customer’ should occur as early as possible in the project.
For every project artifact serving a role as a boundary object in the project, its role
for the attainment of project goals as well as the rationale behind its current state should
be made explicit, opening up for scrutiny and negotiation among project stakeholders.
A representation of the relationship between artifacts and stakeholder goals should be
incorporated into the artifacts themselves. This can be achieved by imposing the use of
standards and templates explicitly referring to stakeholder goals. Also, there are
standard functionality shared workspace tools adequate for providing the necessary
persistence, content structuring, workspace awareness and access for the communities
involved. Such tools should be utilized in the projects.
5.3. Limitations to our study
Our case material is limited in scope and time, although we draw on materials from
two different learning institutions. In-depth interviews with all relevant stakeholders,
combined with a rich written material should lead to satisfactory internal validity of
findings. External validity is mainly determined by our research approach. An
intensive, qualitative approach tends to produce results strong on accuracy, but weaker
on generalization [17]. This indicates that our findings will be most relevant in contexts
similar to our cases, i.e. for customer driven projects in SE at the Bachelor level.
6. Conclusion
Our empirical findings indicate that students consciously balance stakeholder goals
in their projects, but that the understanding of these goals and their connection to
various project artifacts often is inadequate. We suggest that in the pedagogical design
of the courses, a stronger focus should be placed on the connections between
stakeholder goals and project artifacts. These connections should be made visible and
negotiable in connection with boundary objects: artifacts playing a role in the goal
attainment of more than one stakeholder Scaffolding for effective development of these
artifacts implies a focus on project process as well as on technological infrastructure.
20th Conference on Software Engineering Education & Training (CSEET'07)
0-7695-2893-7/07 $20.00 © 2007
Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 08:55 from IEEE Xplore. Restrictions apply.
105