Hardware Reference
In-Depth Information
5.5 Focus on a Process: The Design Process
Recording the project in action.
According to ISO/IEC 12207, outcomes of the
7.1.3 Architectural Design and 7.1.4 Software Detailed Design Processes are: a) a
software architectural design is developed and baselined that describes the software
items that will implement the software requirements; b) internal and external inter-
faces of each software item are defined; c) consistency and traceability are established
between software requirements and software design and d) a detailed design of each
software component, describing the software units to be built, is developed.
For the Design Process, 12207 recommended tasks and 15504 base practices are
roughly the same:
1) transformation of the requirements for the software item into an architecture that
describes its top-level structure and identifies the software components.
2) development and documentation of a top-level design for the interfaces external to
the software item and between the software components of the software item.
3) development and documentation of a top-level design for the database.
4) development and documentation of preliminary versions of user documentation.
5) definition and documentation of preliminary test requirements and the schedule for
Software Integration.
Our ILI framework, considered as representative of VSEs processes, decompose the
Design Process in 3 SE Activities: Adjusting the Design, Exemplary Software Design,
and Software Design (including Database Design as a sub-activity).
If we have a look at the information recorded in the observatory by team members,
they performed two kinds of self-confrontations. The structure of self-confrontations
of the former kind, performed at the end of the task, reflects the structure of recom-
mended tasks as they may be found in the SE Activity description. For instance, for
the Exemplary Software Design Activity, the description stresses the identification of
Computer Software Components, the requirements allocation to the components and
the components specification. So, each participant to this activity recorded its own
participation in a Course-of-action unit kept to the Activity description. The latter
kind of self-confrontation was performed as team members prepared the Software
Design Process Review, a formal review. They have to create a synthetic description
of the Design Process and to record it in its associated Work Scenes (see figure 4).
Participants created Steps-in-action embedding individual Course-of-action units and
established inter-wikis links with the corresponding 12207 Processes. It is not sure
that the 12207 outcomes and tasks were confronted to the performed actions, but it
indicates an attempt to link the course-of-action at the horizon of SE standards.
Recording team competency development.
Periodic inventories of team members
are recorded within the eCompas tool. A copy (in a Word format) is stored into the
observatory. Focusing on the Design Process, we may note that a team member has
participated to the 3 SE Activities defined for the Design Process (see above). As the
year started, he assesses himself at the maturity level - 1 - (or - none) for the process
as a whole and for each associated abilities. Inside his company, he acts as a software
developer and has very little opportunity to improve design skills. After the Software
