|
|
 |
| |
| FAMILIES
activities are structured in 6 work packages: |
| |
|
|
| |
| |
Work
package 1: Reuse economics and family transition |
|
|
The goal of this work package is to consolidate
economical and technical issues regarding the adoption or transition
of system family engineering practices.
|
|
| |
Task 1.1 Reuse economics
framework |
| |
Task 1.2 System family
transition economy |
| |
Task 1.3 Family marketing,
domain and scoping economics |
|
| |
| |
Work
package 2: System family maturity
|
|
|
The objective of the work package is to merge the existing CMMI
and CAFÉ process frameworks into a single system family
maturity framework with an ample consensus from industry.
The current de- facto standard process maturity framework CMMI
(earlier CMM) does not take system family development into account.
The SEI publication Software Process Improvement and Product Line
Practice: CMMI and the Framework for Software Product Line Practice,
by L.G. Jones and A.L. Soule (CMU/SEI-2002-TN-012) does not indicate
a substantial improvement from the SEI itself, which is both involved
in CMMI and Product Line Practices.
On the other hand, the CAFÉ project and its predecessor
ESAPS have addressed several engi-neering practices regarding
system family engineering in depth, ranging from requirements
to architecture, derivation and testing in the context of a specific
domain.
We believe that only companies mature in system family engineering
will succeed here.
|
|
| |
Task 2.1 System family
maturity framework |
| |
Task 2.2 System family
maturity specific practices |
| |
Task 2.3 Tool support
framework |
|
| |
| |
Work
package 3: Family Quality |
|
|
The objective is to provide a set of techniques and methods that
guarantee the quality of system families in an organisational
context and addressing new challenges. Quality aspects have already
been addressed in ESAPS and CAFÉ. For example much effort
has been devoted to architectural assessment and family testing.
The obtained results need to be integrated in the process context
of the organisation.
At the same time, the technological and market evolution poses
new problems to family development organisations (e.g. dynamic
reconfiguration of systems by end-users, security issues, dependability
from 3 rd party software. Service-based systems)
|
|
| |
Task 3.1 Needs Fulfilment
Qualities |
| |
Task 3.2 Execution Qualities |
| |
Task 3.3 Evolution, Adaptation
and Maintenance Qualities |
|
| |
| |
Work
package 4: Model driven family engineering |
|
|
This Work package builds upon the MDA initiative for consolidating
the system family engineering approach into a Model-Driven system
Family Engineering approach (MDFE). Model Driven Family Engineering
will provide, organise, and manage not only a repository of common
assets, but also an explicit repository o f models including development
know-how. A corollary to this is that stable standards on know-how
can emerge and be shared as well. Model driven family engineering
will provide full support for weaving, assembling, transforming
and refining all the choices up to implementation models specific
to the particular execution infrastructure.
The high-level models capture the core knowledge of the family,
whereas the low-level models realise the requirements on given
platforms, according decisions done during the derivation. ESAPS
and CAFÉ activities on variability modelling, decisions
modelling or product derivation were an initial attempt to introduce
model driven engineering as a way to address system families aspects.
|
|
| |
Task 4.1 Domain and application
modelling practices and techniques |
| |
Task 4.2 MDFE methodological
components creation |
| |
Task 4.3 Model transformation
for MDFE |
| |
Task 4.4 Model Driven
Family Engineering supporting practices |
|
| |
| |
Work
package 5: Families Integration |
|
|
Support the merging of existing assets in to a single family.
The business interest is to effectively use the software that
is already available, and introduce software reuse on a very wide
scale. Not only software, other assets are as important. We have
to focus on systems as a whole. In many cases, several families
already exist and in order to keep their maintenance and construction
manageable and to reduce cost we have to introduce reuse over
family boundaries. This means we have to group our families into
populations. This is a next step towards a higher level of reuse.
Because of business reasons each family stays in existence, and
systems have to be produced within these families.
|
|
| |
Task 5.1 Architecture
consequences of integration |
| |
Task 5.2 Process and
organisation consequences of integration |
| |
Task 5.3 Asset recovery
for maintenance, manufacturing and supply |
|
| |
| |
Work
package 6: Dissemination |
|
|
One of the most valuable assets extracted from the ESAPS and
CAFÉ projects has been the building of the European system
family community. In FAMILIES we want to continue this trend by
giving the community the necessary tools to be aware of all the
European, and world-wide initiatives in this topic. On the other
hand, the results of FAMILIES have to be well known by tool providers
for them to be aware of the real needs of the European industry
to approach system family development.
|
|
| |
Task 6.1 Families standardisation
& books |
| |
Task 6.2 Internal dissemination |
| |
Task 6.3 External dissemination |
| |
Task 6.4 Tool board |
|
| |
| |