Page 287 - Software and Systems Requirements Engineering in Practice

A

ç
D
ç
P
I
R
S
H
U
E
T
E
A
P
$
4
E
T
ç
C
I
Q
H
N
E
L
E
V
O
E
N
P
M
ç ç # # H A P T E R ç ç ç 2 2 A P I D ç $ E V E L O P M E N T ç 4E C H N I Q U E S ç ç
REQUIREMENTS AND POTENTIAL SOLUTIONS &OR WEB APPLICATIONS
DEVELOPING AN EXECUTABLE PROTOTYPE CAN EVEN BE FASTER AND CHEAPER
THAN DEVELOPING A VISUAL BUT NONEXECUTABLE PROTOTYPE
%XECUTABLE PROTOTYPES CAN BE CLASSIFIED ON SEVERAL DIMENSIONS !
COMMON DECISION IS WHETHER THE PROTOTYPE IS GOING TO BE A THROWAWAY
OR AN EVOLUTIONARY STEP TOWARD THE FINAL PRODUCT 4HIS DECISION
DEPENDS ON A NUMBER OF TECHNOLOGICAL FACTORS INCLUDING ACTUAL
TECHNOLOGY SELECTION TECHNOLOGY SUPPORT FOR QUICK CHANGES AND HOW
FAMILIAR THE DEVELOPERS ARE WITH THE IMPLEMENTATION TECHNOLOGIES
AND TOOLS 4HE MOST IMPORTANT FACTOR IN DECIDING WHETHER AN
EVOLUTIONARY PROTOTYPE OR A THROWAWAY ONE IS THE BETTER APPROACH IS
BASED ON THE CURRENT MATURITY OF THE EXISTING SET OF REQUIREMENTS )F
THE REQUIREMENTS ARE VERY FUZZY IT IS HIGHLY IMPROBABLE THAT THE
MAJORITY OF ARCHITECTURE AND DESIGN DECISIONS MADE DURING THE
PROTOTYPING PROCESS WILL BE APPLICABLE TO THE ACTUAL PRODUCT
DEVELOPMENT
"RANCH PROTOTYPES ARE THE MOST COMMON TYPE OF PROTOTYPING USED
BY MANY SOFTWARE DEVELOPMENT ORGANIZATIONS ! BRANCH PROTOTYPE IS
CREATED EVERY TIME A DEVELOPMENT TEAM STARTS TO WORK OUT SOME
UNCERTAIN ISSUE BY MODIFYING THE EXISTING PRODUCT CODE WITHOUT
NECESSARILY PLANNING TO ADD THE CHANGES TO THE PRODUCT )F THE
PROTOTYPING WORKS OUT AND THE SOLUTION IS DEEMED SATISFACTORY THE
PROTOTYPE IS GENERALLY CLOSE ENOUGH TO THE MAIN DEVELOPMENT TRUNK
THAT IT CAN BE MERGED BACK WITHOUT LARGE DISRUPTIONS )N MANY CASES
THE MAIN BENEFIT OF A BRANCH PROTOTYPE WILL BE THE IDEAS AND KNOWLEDGE
GAINED AND THESE MAY BE APPLIED DIRECTLY IN THE DEVELOPMENT OF THE
PRODUCT WHILE MAKING SURE TO HARMONIZE THEIR USAGE WITH THE SYSTEM
ARCHITECTURE OR ADJUSTING THE ARCHITECTURE IF REQUIRED
#REATION OF FULLY EXECUTABLE PROTOTYPES IS OCCASIONALLY REQUIRED IN
ORDER TO UNDERSTAND THE TECHNOLOGICAL VIABILITY OF THE PLANNED
SOLUTIONS )N SUCH SITUATIONS IT IS VERY ADVANTAGEOUS TO DEVELOP A
REALISTIC TARGET SCENARIO ON TOP OF THE VIABILITY PROTOTYPE IN ORDER TO
CREATE A FULL VERTICAL SLICE OF THE TARGET SYSTEM IN THE TARGET TECHNOLOGY
;0AULISH = 4HIS DOES NOT REQUIRE THE PROTOTYPE TO BE EVOLUTIONARY
EVEN THOUGH MANY LESSONS FROM THE PROTOTYPE WILL PROBABLY BE
CARRIED INTO THE IMPLEMENTATION AND SOME OF THE CODE MAY EVEN END
UP BEING REUSED
4HE PRIMARY DRIVER FOR REQUIREMENTS ELICITATION USING PROTOTYPING
TECHNIQUES IS TO GATHER USEFUL INFORMATION AS EFFICIENTLY AS POSSIBLE )N
SOME SITUATIONS A SIMPLE PROTOTYPE CAN SERVE AS AN INTERMEDIATE STEP
IN COLLECTING INFORMATION THAT WILL HELP CREATE A MORE COMPLEX
EXECUTABLE PROTOTYPE THAT CAN BE FULLY EVALUATED BY CUSTOMERS USERS
)N MOST CASES THE INITIAL PROTOTYPE TAKES THE FORM OF A USER STORY OR
STORYBOARD BUT IT CONTAINS ENOUGH DETAIL TO ALLOW THE ELABORATION OF
NECESSARY DETAIL FOR A MORE COMPLEX PROTOTYPE 4HIS APPROACH IS
COMMONLY USED IN AGILE SOFTWARE DEVELOPMENT PROJECTS BUT WITHOUT
LOOKING AT THE USER STORIES AS A FORM OF PROTOTYPING 7E THINK THAT AS