Hardware Reference
In-Depth Information
Software development never uses a repeated scheme and it may be difficult to in-
terrupt a software engineer at work and to provoke a verbalization of what he/she is
doing and why. In §2.3 we gave an overview of what, in the observable activity is (i)
presentable, (ii) accountable and (iii) commentable by the actor.
Products and documentary resources are main objects of (i) presentation as they
describe the inputs and outputs of the activity. The “historical” context of resources'
use and products' production has to be recorded too. This can be described in terms of
events and processes, involving occurrences of agents (people) and artifacts (products
and resources) meeting in space (in case of distributed cooperation) and time. As a
first stage, we may consider individual courses of action of the various participants.
At a second level, a collective action involves parts of several individual courses of
action which take place synchronically or sequentially. We need to divide individual
course-of-action in smaller units, that we call course-of-action unit. Each event of
interest has to be (ii) accounted in an instance of Course-of-action Unit in relation
with people and artifacts involved. It provides a kind of project journal. A journal
may be seen as a kind of reflective practice that is a device for working with events
and experiences in order to write (iii) comments and extract meaning from them.
5 A Case Study
5.1 Introduction
In spring 2007, local employers in Brest decided to implement a recent French law on
professional training. This law requires that 3% of employees be under 'sandwich' (or
work placement) conditions. A lot of companies choose to use a system called “Con-
trat de professionnalisation” (professionalization contract) over a period of 12 months.
During these 12 months, the full-paid employee is attending university for certain
periods. For contracts involving our computing department, we dedicated an innova-
tive program called “Software Engineering by Immersion” ('Ingénierie du Logiciel
par Immersion'). The main feature of this last year of the Masters programme is to
learn software engineering by doing, without any computing course but with a long-
term project as the foundation of all apprenticeships. Alternating employees are at-
tending university in 9 periods of 2 consecutive weeks and work in team of 6 in order
to build a complete information system.
The program's rhythm is based on the lifecycle of a project organized into stages.
Each stage was arbitrary sized to 2 weeks due to the constraints of alternation. The
cycle is: Stage 0: Warm-up; Stage 1: Project set-up; Stage 2: Requirement capture;
Stage 3: Requirement analysis; Stage 4: Design; Stage 5: Software construction; Stage
6: Software construction; Stage 7: Integration and Verification; Stage 8: Qualification
and Deployment.
This case study is based on the activity of a team of 6 young software engineers
(the six former authors) accompanied with the two latter authors acting as partici-
pants-to-observe: one having a direct contact of the team members, sharing their envi-
ronment and taking part in the activities of the team, the other one conducting reviews
