Hardware Reference
In-Depth Information
For VSEs, each category contains a number of standards that put them out of reach.
There is a need for an umbrella standard within each category. The IEEE/IEC 12207,
Software Life Cycle Processes [16], provides this umbrella for all of the customer and
process standards. An on-going initiative of ISO should provide lifecycle profiles for
Very Small Enterprises (VSEs) [7].
4.2 VSEs Faced to the 12207
Confronted to the 12207, a software engineer in a VSE is at a loss (
1
“like a goose
finding a knife” as French people say). First, this standard has received major changes
since 1995: Amendment 1 in 2002, Amendment 2 in 2004, and a complete revision in
2008. Secondly, there are currently 43 processes in the 12207:2008 [16], organized in
7 process groups. As an example of the gap with the VSEs needs, the emerging stan-
dard “Software Engineering - Lifecycle Profiles for Very Small Enterprises (VSE)”
[7] contains 2 processes: Project Management (PM.1) and Software Implementation
(SD.1). PM.1 is subdivided in 4 sub-processes (Project Planning, Project Plan Execu-
tion, Project Assessment and Control, Project Closure) and SD.1 is subdivided in 6
sub-processes (Software Implementation Initiation, Software Requirements Analysis,
Software Architecture and Detailed Design, Software Construction, Software Integra-
tion and Tests Product Delivery).
It is not sure that a software engineer in a VSE share the same meaning of these 10
names of sub-processes (from Project Planning to Software Integration and Tests
Product Delivery) with a client or a colleague of a major company engaged in any SPI
program such as ISO/IEC 15504 or CMMI. However, they will try to communicate
and may sign a contract, but they don't speak about the same things. This lack of
understanding illustrates the existence of two theories of action - for a software engi-
neer as for any practitioner -, as defined by Argyris and Schön. They have established
a distinction between those theories that are implicit in what we do as practitioners
and managers (theories-in-use), and those on which we call to speak of our actions to
others (espoused theory). “When someone is asked how he would behave under cer-
tain circumstances, the answer he usually gives is his espoused theory of action for
that situation. This is the theory of action to which he gives allegiance, and which,
upon request, he communicates to others. However, the theory that actually governs
his actions is this theory-in-use [10].” We may ask question about the extent to which
theory-in-use fits espoused theory. Reflection may be a help to discover the theory-in-
use and to reveal the nature of the 'fit'. We believe that the observatory of course-of-
action - adapted to the software engineering field - may support this process.
4.3 What Can Be Observed?
This significant activity for the actors includes action and communication, but also
other elements: interpretations, feelings, judgments, …The data necessary to study the
course of action must include continuous observations of the behavior of action and
communication in a work situation as well as different kinds of instigated verbaliza-
tions from the actors which would provide access to other elements [4].
