Difficulties Team Imp. Imp. tot acad ind Tech Tech Base INC1 INC2 INC3 INC4 INC5 INC6 INC7 INC8 INC9 INC10 INC11 INC12 INC13 Obj Gen. Links Dial. Views Reuse EX1 EX2 EX3 EX4 GR1 GR2 GR3 GR4 INC1 INC2 ET1 ET2 Score Rank effortexp exp used taught Model Link Box L 101 1 430 3.2 1.5 ad hoc HB HB Er 5 5 5 5 5 5 4 5 6 5 5 5 4 0 0 1 1 1 0.5 1 K 94 3 270 3 0.2 HB/scratch EB Er 5 5 5 5 5 5 4 5 5 5 4 5 3 0 0 1 1 1 1 1 1 1 E 94 3 260 3.3 0.7 HB/EB HB Er 5 5 5 5 5 5 5 5 6 4 4 5 3 1 0 1 0 1 0 1 1 B 94 3 230 6 1 ad hoc HB EB Er 5 5 5 5 4 5 4 5 3 5 5 5 3 0 0 1 1 1 0 1 1 1 1 O 89 5 4.5 0.5 HB EB Er 5 5 5 5 5 5 4 5 5 4 4 5 3 0 0 1 1 1 0 1 1 D 88 6 3.3 0.7 HB/EB HB Assign3 4 5 5 5 4 5 5 5 5 4 4 4 4 0 1 1 1 1 1 1 1 N 87 7.5 4 1 HB/EB HB Assign3 5 5 5 5 5 5 4 5 3 3 4 5 3 1 0 1 0 1 0.5 1 1 G 87 7.5 3.5 0.2 HB EB Er 4 5 4 5 4 5 5 5 3 4 4 5 3 1 0 0 1 1 0 1 A 84 9 130 3.5 0 HB EB Er 5 4 0 5 5 5 3 5 6 2 4 5 5 -1 1 0 0 0 0.5 1 1 1 1 1 M 81 10.5 2.7 0 HB/EB HB (NR) 4 5 5 5 4 5 3 5 5 3 4 4 3 -1 0 0 0 1 -1 1 C 81 10.5 4 0.8 HB/EB HB (NR) 4 5 4 5 3 5 3 5 3 4 4 4 4 0 1 0 1 1 1 1 1 F 80 12 4.7 0.7 HB EB Er 4 5 5 5 5 5 3 5 3 3 4 4 3 0 0 0 0 0 1 1 1 J 77 13 4 0.1 ad hoc HB EB Assign3 5 5 5 5 5 5 3 5 5 3 4 4 2 0 0 0 0 1 1 1 H 76 14 240 3.3 0.3 HB EB Er 5 5 5 5 5 5 3 5 5 0 4 5 3 -1 0 0 0 1 0.5 1 1 1 I 44 15 230 4.1 1.2 ad hoc HB HB Assign3 4 5 5 5 4 5 3 3 3 0 0 4 0 0 0 0 0 0 -1 1 1 1 8 4 1 1 3 1 6 1 2 4 2 1 Column A is the team identifier. Column B is the implementation score (computation is described in the TR). Column C is the team's rank in class, based on implementation score. Column D is the team's total effort expended on implementation, in hours. Column E is the average number of years team members have spent in college. (I.e. 4 => all seniors) Column F is the average number of years team members have worked as software engineers in industry. Column G is the specific adaptation technique used during development (key is included in the TR). Column H is the technique taught to the team (either Hierarchy-Based or Example-Based). Column I indicates how the team began implementation. Er indicates the team implemented the system on top of the Er application that came with ET++. Assign3 indicates the team implemented the system on top of a very simple application (in effect, on top of the framework itself). (NR) indicates no response was received. Columns J through V indicate how well the functionality for each increment (collection of requirements) worked. 0= func. missing 1= program stops when func. invoked 2= func. cannot be used 3= func. can only partly be used 4= minor or cosmetic deviation 5= func. works well Column W reports the team's comments on the object model. 1= stayed close to object model during implementation -1= final system strayed from original object model 0= not reported (Columns X through AA rate the level of sophistication at which various requirements were implemented) Column X reports the level of sophistication at which links were implemented. 1 = 1-to-Many relationships were permitted. 0 = 1-to-1 links only. Column Y reports whether the system could handle multiple links between the same two classes. 1= unique links were drawn in this case 0= links overlapped in this case (reduced functionality). Column Z reports whether dialog boxes were working correctly in the team's system. 1= working 0= functionality was only partly working Column AA reports how the team handled the requirement that multiple views of the data be allowed. "1= views could be added dynamically by the user, and resized" 0= views could only be resized Column AB reports the teams' self-assessment, in terms of how much functionality in the system was reused from the framework and example applications. 0 = less than half of the system was the result of reuse. 0.5 = about half of the system came from reuse 1 = more than half of the system -1 = not reported Columns AC through AN show which teams experienced some of the more common difficulties. A '1' indicates the team did report having the associated difficulty. The teams had the following difficulties due to the examples: EX1 Increments were hard which required a lot of functionality to be written from scratch - either because there were no similar examples, or because appropriate examples were hard to find. EX2 Difficulties because examples didn't correspond to a consistent organization. EX3 Had problems when someone used example code without understanding it. EX4 Hard increments were the ones they tried to do without looking at examples. The following difficulties due to the technique used by the group were reported: GR1 Didn't concentrate enough on object model. GR2 Didn't have as much time to extend code from examples as was necessary. GR3 Had trouble with some increments because implemented extra functionality or wrongly the first time. GR4 Had a hard time with some increments because didn't know how to approach them. Some difficulties were intrinsic to specific increments: INC1 Hard increments were the ones that asked for a lot of functionality. INC2 Had trouble with increments requiring visual/geometrical issues. Although there were many problems with ET++, some were reported that focused explicitly on its interaction with the technique used: ET1 Had a hard time figuring out where functionality is called, following flow of control. ET2 Hard increments were the ones for which ET++ provided a lot of potential classes to use but little guidance as to the more appropriate.