Page 303 - Software and Systems Requirements Engineering in Practice
P. 303
E
D
T
B
U
Q
U
E
ç
2
R
ç
R
I
T
I
S
N
E
I
N
G
N
G
I
E
R
M
E
E
I
R
ç
%
S
N
T
E
H
ç ç # H A P T E R ç ç ç $ $ I S T R I B U T E D ç 2 E Q U I R E M E N T S ç % N G I N E E R I N G ç ç
#
T
P
A
AMONG THE REMOTE TEAMS IS ENCOURAGED 5NLIKE THE EXTENDED
WORKBENCH MODEL APPROACH THIS APPROACH DOES NOT REQUIRE THE
CENTRAL TEAM TO COORDINATE THE COMMUNICATIONS AMONG THE DISTRIBUTED
TEAMS
4HE '30 VERSION n PROJECT TEAM WAS ORGANIZED AS A CENTRAL
COORDINATING TEAM A DISTRIBUTED REQUIREMENTS ENGINEERING
ARCHITECTURE TEAM SEVERAL REMOTE DEVELOPMENT TEAMS AND A REMOTE
INTEGRATION TESTING TEAM 4HE CENTRAL COORDINATING TEAM WAS
RESPONSIBLE FOR PRODUCT IDENTIFICATION AND ASSIGNMENT OF COMPONENTS
TO THE DISTRIBUTED DEVELOPMENT TEAMS !N EXAMPLE PROCESS DESCRIPTION
SUMMARY FOR A SYSTEM OF SYSTEMS MODEL IS GIVEN IN &IGURE
&OR '30 VERSIONS n MORE OF AN OPEN SOURCE APPROACH WAS
USED AS COMPARED TO '30 VERSIONS n WITH COMPETENCE CENTERS
LOCATED AT THE REMOTE SITES 4HE SYSTEM OF SYSTEMS APPROACH WORKED
WELL FOR A PROJECT OF THE SIZE OF THE '30 AND WITH STAFF FROM SIMILAR
CULTURES 4HE EXTENDED WORKBENCH MODEL WITH ITS HUB AND SPOKE
ORGANIZATION IS DIFFICULT TO SCALE FOR VERY LARGE PROJECTS SINCE AS THE
PROJECT GETS LARGER THE CENTRAL TEAM REQUIREMENTS ENGINEERS CAN OFTEN
BECOME OVERLOADED WITH COMMUNICATIONS FROM THE REMOTE TEAMS !S
THE CENTRAL TEAM REQUIREMENTS ENGINEERS MUST ANSWER ALL FUNCTIONALITY
AND PERFORMANCE QUESTIONS FROM THE REMOTE DEVELOPMENT TEAMS
THEY CAN QUICKLY BE VIEWED AS COMMUNICATION BOTTLENECKS 4HUS
DISTRIBUTING 2% EXPERTISE TO REMOTE SITES SEEMS TO HELP OPTIMIZE
COMMUNICATIONS FOR VERY LARGE PROJECTS (OWEVER FOR MANY 2% TASKS
$! & & &$ ( !" & % %&
$ & &'$ !$ & & $ %
& * '% %%
% ! % & * &
! "! &% #' $ &%
& * ! " & & $ & !
)" $&% ! "! & %&%
!$ $ & &'$
#' $ & ! ' & &
! "! & %&%
!$ ( !" & ( ) '& & $ & !
%& % #' $ &% %&%
1, Ê£ä°{Ê Ý>«iÊÃÞÃÌiÊvÊÃÞÃÌiÃÊ`i
