[Title will be auto-generated]

Page 1

A MODEL FOR THE MANAGEMENT OF DESIGN PROJECT ISSUES. THE CASE OF CNES MICROSATELLITES DESIGN C. BELLEVAL, I. DENIAUD, C. LERCH BETA, CNRS UMR 7522 Strasbourg University

CRECOS 2010- Helsinki


Agenda  State of the art  Innovating design characteristics  Myriade Case (microsatellites design)  Contradictions Network  Requirements System  Design Analysis Model  Conclusions and Future Works

System Engineering


State of the art  Design Approaches  Traditional Approach  Simon, 1969: Design is problem solving  Pahl & Beitz, 1988: sequential model, complicated products  Problems  Product-system and project-system complexity  Taking into account of the system effect  Taking into account of all stakeholders

 New Approaches  Liu, 2000: problem structuring stage  Cross, 2001: co-evolution problem - solution  Schön, 1995: thinking after action + thinking while acting  Hatchuel & al. 2002: C-K theory, expanded rationality


Innovating Design  Characteristics  The problem statement is not defined or ill-defined, and

unsolved: Hatchuel, 2002 ; Choulier, 2008  The problem to be solved is contradictory  Exploratory process  The objective is built during the design process  New knowledge development: Lerch, 1998  Design of a new and adapted solution  Multidimensional Approach: Nightingale 2000, Robin and Girard 2006, IPPOP project  Interdisciplinary communication (Concurrent engineering)

System Engineering Context


System Engineering  Co-operative and interdisciplinary process of problem solving (AFIS)

 Process implemented to define, make evolving and check the definition of the system (AFIS)

 Forsberg and Mooz Model


Myriade Case  CNES 1998: a line of microsatellites  Non-functional Requirements  Physical Requirements Weight < 120 kg; volume < 1 m3; power on-board 100 W

 Service Quality Requirements  Development costs < 3 million €  Design and execution time: two years  Operational life cycle > 2 years  Commercial off the Shelf – COTS  Operational and Maintenance Requirements  Autonomy, control since the ground, etc.  Verification and Validation Requirements  Tests, inspections, etc.


Contradictions Network ORGANIZATION

dimensions

Ambidexterity excluded ex ante

(3b)

Organisational Contradiction

TECHNICAL

Systeme Requirements and Constraints

COGNITION

(1)

Cooperation with SSTL excluded (no preliminary spin-in)

Technical Contradiction

Innovating Solution

(2)

Organis. Blocking (4b)

(4c)

Technical Blocking

(4a) Cognitive (3a) Contradiction

Cognitive Blocking

Organis. Arbitration (5c) Technical Arbitration (5a) Cognitive Arbitration (5b) !me

Program Setup

On-board Computer Design

Program Stall

Downgrading Requirements


Myriade Case  Organisational requirements and project management requirements  Concurrent engineering  New acceptable risks redefinition  Quality management  Organisational Ambidexterity

 Cognitive requirements  Engage its actors in an evolution of their action theories (Argyris and Schön 1978)

 Double-loop organisational learning


Projects Organisation Mission Success First

Space: hostile environment

Faster: synchronization with the other sectors

Better: Equipment Miniaturization

Equipments Redundancy

Important weight

Long design time

Cheaper: Duplicate the projects number (Economy of scale and variety)


SPOT 5

Weight: 3 000 kg Design Time: 10 years Estimated Cost: 120 million €

DEMETER

Weight:130 kg Design Time: 12 month Estimated Cost 3 million €


Requirements System Requirement 1..*

Functional Requirement

1..*

Non-Functional Requirement

1..*

Project 1..* Requirement

Cognitive 1..* Requirement

1..*

1..*

1

1

1..*

Product 1..* 1..*

Function

1..* 1..*

Functional Architecture

1..* 1..*

1..* 1..*

0..1 1

Components 1..* 1..*

Physical Architecture

Project

0..*

1

Organisation 1

0..*


Design Analysis Model Needs Analysis

Requirements Control

[completeness = false] [completeness = truth]

Propose an Architecture

Remove Contradiction

[contradiction = truth] Contradiction

[blocking = false]

Analysis [contradiction = false]

Design Verification Requirements Arbitration

[arbitration = truth] [arbitration = false]

Accept Solution

[blocking = truth]

Solution Give up


Conclusions  Co-evolution of the problem and its solution  During the requirements deployment in design

project, the constraints appeared in 3 dimensions: technical, organisational and/or cognitive

 The interactions between the 3 dimensions generate

contradictions which influence the strategic direction of design project. Contradictions are propagated from one dimension to another

 Compromise and overcome contradictions are thus

strategic choices for a design project. They must both take into account in the design project analysis model


Future Works  Integration of our model in a design project management software  Decision representation which integrates various points of

view: organization/product/project. The presented UML models can be transformed into relational model and implemented in a relational database making it possible to manage the integrity of the data and to keep the memory of the innovating design project  Verified requirements with each stage of design process and lead us to a validated solution in the form of simulated virtual prototype  Identify and analyze in detail the contradictions using system engineering tools  Overcome technical, organisational and cognitive contradictions appeared during design project


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.