Prototyping vs. Specifying. Evaluation of data of a Software Engineering Class Project. Individual Study Spring 1962.

Transcription

1 Prototyping vs. Specifying Evaluation of data of a Software Engineering Class Project Individual Study Spring 1962 Thomas Seewaldt

2 1. Introduction 2. The source data 2.1 Beginning questionnaire, product size, distribution of source code by function, documentation size, maintenance score 2.2 Productivity, maintainability vs. product size and pages of listing 2.3 Performance, performance vs. size, vs. effort, vs. maintainability, vs. size of design spec., and vs. programming experience 2.4 Effort distribution by activity and phase 2.5 Problem reports 3. Analysis of variance 4. Follow up questionnaire 5. Comparison of the COCOMO prediction with the real effort 6. Interpretation of the project data 7. Comparison USC project with UCLA project 8. Conclusion

3 Appendices A B C D E Awk program to count lines of pascal source code Results of calculations on the timesheets Answers on the follow up questionnaire COCOMO estimation of the team projects Program to enter timesheets and perform calculations on them

4 List of figures 1 Distribution of source code by function 2 Program size vs. development effort 3 Maintainability rating vs. program size 4 Maintainability rating vs. pages of listing 5 Performance score by group type 6 Performance score vs. program size 7 Performance score vs. development effort 8 Maintainability rating vs. performance score 9 Distribution of development effort by activity (absolute values) 10 Distribution of development effort by activity(relative values) 11 Distribution of total development effort by phase 12 Effort distribution by phase and activity (Ave. group type 1) 13 Effort distribution by phase and activity (Ave. group type 2) 14 Cumulative effort distribution by phase and activity (Ave. group type 1) 15 Cumulative effort distribution by phase and activity (Ave. group type 2) 16 Effort distribution by activity (USC vs. UCLA projects)

5 List of tables 1 Beginning questionnaire, product size, distribution of source code by function, documentation size, maintenance score 2 Maintainability rating 3 Productivity, maintainability vs product size and pages of listing 4 Performance rating 5 Performance, performance vs. size, vs. effort, vs. maintainability, vs. size of design spec., and vs. programming experience 6 List of available timesheets 7 Effort distribution by activity 8 Effort distribution by phase and activity 9 Number of problem reports 10 Analysis of variance 11 Follow up questionnaire 12 Answers on the follow up questionnaire 13 COCOMO prediction vs. real effort 14 Comparison USC data with UCLA data

6 1. Introduction In this paper the evaluation of data gathered during a software engineering course project in winter 1982 at the University of California, Los Angeles (UCLA) will be presented. During this project, 7 groups consisting of 2 or 3 people developed a small software product. 4 groups wrote requirements and design documents before coding, 3 groups built a prototype. Both the documents and the prototype were reviewed by the lecturers, and an acceptance test took place at the end of the quarter. The data collected during this project were evaluated in Spring 1982 in an individual study project supervised by Barry W. Boehm and Terry Gray. The results of this study are assembled in this paper. The source data, its analysis results, and the assumptions made when collecting and analyzing the data are described in chapter 2 to 5 in order to give a solid basis for final conclusions. Interpretation results and conclusions are gathered in chapter 6. Finally, chapter 7 compares the project results with the results of a similar project, which was conducted at the University of Southern California in fall 1979.

7 2. The source data 2.1 Beginning questionnaire, product size, distribution of source code function, documentation size, maintenance score The first group of data in table 1 shows the team size, the programming and virtual machine experience, and the GPA of the team members. The data are taken from the background surveys filled out by each student at the beginning of the quarter. The next group of data shows the product size and the line of code distribution per function. For counting the lines, the string editor awk, running under UNIX, was used. The awk program, developed for this purpose, is documented in appendix A. A demonstration program, showing which lines are counted by the program is also included there. The distribution of source code by function is shown in figure 1. The next block of data shows the size of the delivered documentation material. At the end of the quarter, each student indicated which product he would like to maintain and ranked the products accordingly (Table 2). The maintenance score is the sum of the ratings of each product multiplied by an adjustment factor, since not every product was rated by the same number of people. The lower the maintenance score, the more people preferred to maintain the product. The last group of data gives information about the development effort through certain deadlines. The procedure, how these data are collected is described in chapter productivity, maintainability, vs. product size and pages of listing In table 3 different productivity measures are established. The productivity is calculated considering the size of the product and the total development effort (DSI/MHtotal), the effort for programming, testing, and fixing (DSI/MH), and the effort for planning, designing, programming, testing, and fixing (DSI/MH). Figure 2 shows the relation between the product size and the total development effort graphically. A "documentation productivity" is established by comparing the delivered pages of documentation (without draft user manual) with the documentation effort. The maintainability is compared with the size of the products and the pages of listing. In order to rate how the values differ within the groups, the standard deviation is

8

9

10

11

12

13 shown as an index to the mean value. To make the standard deviation comparable, it is not given in absolute values, but in percent of the mean value. The lower this percentage is the less the values are spread within the group. A more reliable score of how significant the difference between the groups is compared to the variability within the groups appears in chapter 3. Figures 3 and 4 show graphically the correlation between maintainability, and size of product and listing. 2.3 Performance, Performance vs. size, vs. effort, vs. maintainability, vs. size of design spec., and vs. programming experience The performance of the products was rated in an evaluation session. The rating procedure itself was not. straight-forward. First, a criteria matrix was assembled similar to the criteria presented in /2/. Starting off with this matrix, it turned out that the rating process was somehow unsatisfying. This was due mainly to the fact that the criteria forced the raters to test and rate following a certain very detailed procedure, instead of experiencing the quality of the product a normal user would. This approach also turned out to be very time consuming. Hence, 4 criteria were chosen according to which the products were rated after testing them. The criteria are: Functionality, Frustration, Learning, and Tolerance. Functionality addresses the functions provided by the program, while the frustration score tries to measure how the product behavior corresponds to the user expectations and how easily the user can perform his task. Selfdescriptiveness and ease of learning is addressed by the learning score and the reaction on erroneous input by tolerance. In addition, a score was given on how well the program was debugged. The detailed ratings are shown in table 4. The score for normal performance in one category was 5. For performance above or below average, points were added or deducted. After testing a product, each of the rating persons scored the product according to the above mentioned criteria. The mean value of these scores was taken as the product score. Table 5 and Figure 5 summarize the performance scores. In addition, the performance score is compared with product size, development effort, maintainability rating, pages of design specification, and average programming experience of the teams. Again, the standard deviation is given in percent of mean in order to establish comparable values. The comparison is done for the total performance

14

15

16

17

18

19 score without the "Bugs-score" (first line of each item) and with the "Bugs-score" (second line). Figure 6 shows the comparison between performance and size graphically, figure 7 the comparison between performance and development effort. The different correlations for the two group types, shown in these figures, are later confirmed by the analysis of variance (chapter 3). In figure 8 maintainability and performance are compared graphically. To invert the scaling on the performance axis, the performance score was subtracted from 22 and the result used as score in figure B. 2.4 Effort distribution by activity and phase To monitor the effort spent for different activities, the students were given time sheets and asked to turn them in every week. The available time sheets are shown in table 6. For all missing time sheets, except the sheets of the first week, a time sheet was assumed containing the average time that all students of the same group type spent during that week. When time sheets of the first week were missing, it was assumed that these students spent no time for the project. In order to handle the large number OF time sheets, a program was developed to enter the data into the computer and to perform different calculations on these data. These programs are documented in appendix B. Appendix C contains the results of several calculations performed on the time sheets. These results are the basis for the tables and figures presented in this chapter. Table 7 and Figure 9 and 10 show the average effort distribution by activity for each group type in total as well as in percent of the total. Table 8 and figure 11 to 15 show the effort distribution broken down by phase. Since the deadlines (SRH, PDR, prototype exercise) were on Wednesday, Wednesday is used as a week boundary. However, in order to include every day in the calculation, the boundary of the first week was extended to Monday (project start), and the boundary of the ninth week to Sunday (project finish). 2.5 Problem reports In table 9 the number of problem reports is compared with the number of pages of the corresponding document. Again, the standard deviation is given in percent of the mean value.

20

21

22

23

24

25

26

27

28

29

30

31

32

33 3. Analysis of variance In order to investigate differences between the data of the specifying and prototyping groups and between the data of the 2 person and 3 person groups, an analysis of variance was conducted. The analysis OF variance is a statistical method to compare the variability of data within a group with the variability between the groups. A score is established indicating how significant differences between groups are. When calculating this score, not only the variability but also the size of the groups is taken into consideration. This is done in a way that the smaller the groups are, the larger the difference between the groups must be to be considered significant. The main data, collected in chapter 2, were analyzed using the statistical package SAS, running on a IBM The analysis was conducted for two group configurations: 1. specifying groups vs. prototyping groups 2. 2 person groups vs. 3 person groups The mean value and the significance score (^ PROB>F) for both group configuration and different data is shown in table 10. In statistics the score has to be less or equal 0.05 to be considered significant. For our purpose, scores between 0.1 and 0.05 can indicate nearly significant differences. In table 10 the significant and nearly significant scores are underlined.

34

35

36

37 3. Follow up questionnaire In order to collect more information about how certain factors might have influenced the project data, a follow up questionnaire was assembled. All students who were still available (12 of 18 students) were asked to fill out this questionnaire. The questionnaire is shown in table 11. The answers are collected in table 12 according to the questions and the team people were in. For instance, table 12 shows that 3 people of 3 person teams said that, if they would have been in a 2 person team, their product outcome would not have been different. Appendix D contains the detailed answers of the students.

38

39

40

41

42 5. Comparison of the COCOMO prediction with the real effort Table 13 compares the real effort with the prediction of the COCOMO model. The first block contains the nominal and the adjusted total effort. In the second group the effort for different activities are compared with the corresponding model prediction: - plan with planning and reading effort - design with design effort - programming and integration with programming, integration and test effort The remaining effort reported on the time sheets was equally spread over the three categories of activities. The last block of data shows the effort for the mentioned activities in percent of the total effort and compares it to the model data. The detailed COCOMO estimation print out is attached in appendix E.

43

44 6. Interpretation of the project data The interpretation of the project data is not, or at least not mainly from the author, but mainly from the weekly discussions held during the quarter and from a summary of conclusions by Barry W. Boehm. For the sake of completeness, these conclusions were included in this paper. Specifying vs. prototyping Prototyping correlates with - smaller products (tab. 1, tab. 10)* - less development effort (tab. 7, tab. 10) * - no overall performance loss (tab. 5, fig. 5, tab. 10) - lower on functionality, tolerance - better on learning - frustration product dependent - better maintainability rating (tab, 1,2,10) (but judged worse a5 a basis for planning add-one) - reduced deadline effect (mostly doc'n at end) (fig ) - less programming, testing, fixing at the end - more difficult integration (tab. 10) - no difference in "productivity (DSI/MH) (tab. 3) - proportionally less designing effort (fig. 10) - little difference in code distribution by function (tab. 1, fig. 1) - less documentation, less pp(doc)/mh (tab. 1 3, 10) - less designing, programming more testing, reviewing, fixing (percentwise or per KDSI) - always having something that works - prefered by people with programming experience (tab. 1, 10) * partly due to smaller average team size, but critique comments indicate a definite specification-vsprototype effect

45 - prototype 40-60% of endproduct - high percentage of prototype in endproduct (67-95%) smaller vs. larger teams smaller teams correlate with - slightly smaller products (tab )* - smaller development effort (tab. 7, 10) - higher productivity (DSI/MH)* - lower functionality (tab. 5, 10) - little difference in frustration, learning, tolerance (tab. 5, 10) - proportionally less programming and meeting effort (tab. 7, 10) - people OF larger teams would expect lower product performance, if team size would be smaller (tab. 12) - people of smaller teams would not expect higher performance, if team size would be larger (tab. 12) Development process, effort distribution - deadline effect holds (Fig. ii -15) -> less pronounced for prototype teams - dominant activity is programming (37%, 30%) -> reverse of USC results on programming vs. documentation UCLA : [35,12] USC : [14,30] - reasonably consistent across teams - effort overestimated by COCOMO Development process, other - need more front-end effort * perhaps due to one exceptional project

46 - need more planning, organizing -> critiques, USC project experiences -> strategy with scarce computer resources (10-20% of programming, testing, fixing time was "busy-waiting") - preferred organization highly people dependent 4 critiques : democratic approach best 3 critiques : needed a leader - if 4 more weeks (tab. 12) -> better debugged product, better documentation -> slightly product changes Product characteristics - model calculations take small portion of code (8%, 5%) (tab. 1, fig. 1) - user interface takes most of code (54%, 56%) (tab. 1. fig. 1) - with 1 exception (2303), little variation in DSI/person ( ) - maintainability ratings primarily a function of size - wide variation in product architectures -> very much a reflection of developer personalities

47 7. Comparison USC project with UCLA project In 1978 a similar experiment was conducted at the University of Southern California (USC) /3/. Two groups of 5 and 6 people developed the same product, one coding in FORTRAN the other coding in PASCAL. Both groups followed the specification approach. Unlike the UCLA teams, the USC teams had a fixed team organisation. The data of the USC and UCLA projects are compared in table 14 and figure 16. The UCLA results differ from the USC results in the following points: - the UCLA specifying groups produced larger products and had an higher productivity and effort per person* - the UCLA teams spent - more time for designing and programming - less time for documenting, Fixing, and meeting - the UCLA specifying groups produced, on the average, more documentation than the USC groups - the UCLA teams have, on the average, a higher "documentation productivity" due to teams of type 1 - the USC teams had slightly more problem reports per page of documentation, the UCLA teams more problem reports per page for their requirement specification - the USC teams needed 70% of the effort predicted by CDCOMO, the UCLA teams 33%* * it looks as if the situation at UCLA were more competitive, perhaps due to the larger number of teams participating in the project

48

49

50

51 8. Conclusion The presented class project is a basis for interesting conclusions in the area of software engineering of small products. Although the sample was small, statistically significant results could be established. In three areas the evaluation procedure could be simplified or improved: First, not reporting the effort on physical time sheets but, entering the effort directly in the computer and storing it on line would save a lot of time needed for coding the information in machine processable form. Second, it might be interesting to also have people experienced in maintaining software to rate the maintainability of the products. The results could be compared with the students' rating. Third, using a statistical package earlier in the evaluation process might save calculation effort. In addition, it might be fruitful to use other statistical analysis to draw and to support conclusions. Especially, an analysis of correlation between the different data might be helpful to replace the weaker approach using fraction and. Standard deviation.

52 REFERENCES /1/ B.W. BOEHM Software Engineering Economics Prentice- Hall, Inc., Englewood Cliffs, /2/ W. DZIDA, User-Perceived Guallty of Interactive S. HERDA, Systems D. ITZFELD in IEEE Transactions on Software Engineering. Vol. SE-4, No. 4, Julg 78, p /3/ B.W. BOEHM An Experiment in Small-Scale Application Software Engineering in IEEE Transactions on Software Engineering, Vol. SE-7, No. 5, Sept. 81, p

53 APPENDIX A Awk program to count lines of pascal source code

54 BEGIN {semicolonnr = -10; endnr = -10} {for (i = 1; i <= NF; ++i) {if ( ($i ~ /\(\*/) ($i ~ /\{/} ) {++switch; comment = 1} if ( ($i ~ /\*\)/) ($i ~ /\}/) ) {--switch; comment = 1} if (switch == 0) {if (($i ~ /^if$/) \ ($i ~ /^begin$/) \ ($i ~ /^for$/) \ ($i ~ /^record$/) \ ($i ~ /^case$/) \ ($i ~ /^while$/) \ ) {++count; flag = 1} 1)) if (($i ~ /^end$/) ($i ~ /^end;/)) {if ((NR == semicolonnr + 1} (NR == endnr + {++count; flag = 1} else {++count; ++count; flag = 1} endnr = NR } if (($I ~ /^else$/) && (NR!= endnr + 1)) {++count; flag = 1} if ($i ~ /i/) {if (NR!= endnr) {++count; flag = 1} semicolonnr = NR } } } if ( ( (flag == 0) && \ ((switch > 0) (comment!= 0)) \ ) \ (length == 0) \ ) {if (NR == endnr +I) ++endnr if (NR == semicolcnnr + 1) ++semicolonnr } flag = O comment = 0 } END {print "DSI of ",FILENAME, " : ",count}

55 APPENDIX B Results of calculations on the timesheets

56 Title : total of all timesheets Groups : la - 2c Weeks : 1 (Monday) - 10 (Sunday) Groups : 7 Persons : 18 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

57 Title : group type total Groups : 1a 1d Weeks : 1 (Monday) - 10 (Sunday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT Reading % Planning % designing % programming % documentation % Testing % reviewing % Fixing % Meeting % miscellaneous % TOTAL %

58 Title : group type total Groups : 2a 2c Weeks : 1 (Monday) - 10 (Sunday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

59 Title : group total Groups : 1a Member : 1-3 Weeks : 1 (Monday) - 10 (Sunday) Persons : 3 TOTAL PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL % 473

60 Title : group total Groups : 1b Member : 1-3 Weeks : 1 (Monday) - 10 (Sunday) Persons : 3 TOTAL PER PERSON PERCENT reading % planning % Designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL % 306

61 Title : group total Groups : 1c Member : 1-2 Weeks : 1 (Monday) - 10 (Sunday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL % 296

62 Title : group total Groups : 1d Member : 1-3 Weeks : 1 (Monday) - 10 (Sunday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL % 389

63 Title : group total Groups : 2a Member : 1-2 Weeks : 1 (Monday) - 10 (Sunday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL % 207

64 Title : group total Groups : 2b Member : 1-3 Weeks : 1 (Monday) - 10 (Sunday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL % 473

65 Title : group total Groups : 2c Member : 1-2 Weeks : 1 (Monday) - 10 (Sunday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL % 75 32% 29 12% %

66 Title : until srr Groups : 1a Member : 1-3 Weeks : 1 (Monday) - 3 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

67 Title : until srr Groups : 1b Member : 1-3 Weeks : 1 (Monday) 3 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

68 Title : until srr Groups : 1c Member : 1-2 Weeks : 1 (Monday) - 3 (Wednesday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

69 Title : until srr Groups : 1d Member : 1-3 Weeks : 1 (Monday) - 3 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

70 Title : until pdr Groups : 1a Member : 1-3 Weeks : 1 (Monday) - 6 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % Programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

71 Title : until pdr Groups : 1b Member : 1-3 Weeks : 1 (Monday) - 6 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

72 Title : until pdr Groups : 1c Member : 1-2 Weeks : 1 (Monday) - 10 (Wednesday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

73 Title : until pdr Groups : 1d Member : 1-3 Weeks : 1 (Monday) - 6 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

74 Title : until prototype Groups : 2a Member : 1-2 Weeks : 1 (Monday) - 5 (Wednesday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

75 Title : until prototype Groups : 2b Member : 1-3 Weeks : 1 (Monday) - 5 (Wednesday) Persons : 3 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

76 Title : until prototype Groups : 2c Member : 1-2 Weeks : 1 (Monday) - 5 (Wednesday) Persons : 2 TOTAL PER PERSON PERCENT Reading % Planning % Designing % programming % documentation % Testing % Reviewing % Fixing % Meeting % miscellaneous % TOTAL %

77 Title : activity per phase Groups : 1a 1d Weeks : 1 (Monday) 2 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL % From 1 (Thursday) %

78 Title : activity per phase Groups : 1a 1d Weeks : 2 (Thursday) - 3 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

79 Title : activity per phase Groups : 1a 1d Weeks : 3 (Thursday) - 4 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

80 Title : activity per phase Groups : 1a 1d Weeks : 4 (Thursday) - 5 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

81 Title : activity per phase Groups : 1a 1d Weeks : 5 (Thursday) - 6 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

82 Title : activity per phase Groups : 1a 1d Weeks : 6 (Thursday) 7 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

83 Title : activity per phase Groups : 1a 1d Weeks : 7 (Thursday) - 8 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

84 Title : activity per phase Groups : 1a 1d Weeks : 8 (Thursday) - 9 (Wednesday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

85 Title : activity per phase Groups : 1a 1d Weeks : 9 (Thursday) - 10 (Sunday) Groups : 4 Persons : 11 TOTAL PER GROUP PER PERSON PERCENT Reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL % Until 10 (Wednesday) %

86 Title : activity per phase Groups : 2a 2c Weeks : 1 (Monday) - 2 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

87 Title : activity per phase Groups : 2a 2c Weeks : 2 (Thursday) - 3 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

88 Title : activity per phase Groups : 2a 2c Weeks : 3 (Thursday) - 4 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

89 Title : activity per phase Groups : 2a 2c Weeks : 4 (Thursday) - 5 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

90 Title : activity per phase Groups : 2a 2c Weeks : 5 (Thursday) - 6 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

91 Title : activity per phase Groups : 2a 2c Weeks : 6 (Thursday) - 7 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

92 Title : activity per phase Groups : 2a 2c Weeks : 2 (Thursday) - 3 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

93 Title : activity per phase Groups : 2a 2c Weeks : 8 (Thursday) - 9 (Wednesday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL %

94 Title : activity per phase Groups : 2a 2c Weeks : 9 (Thursday) - 10 (Sunday) Groups : 3 Persons : 7 TOTAL PER GROUP PER PERSON PERCENT reading % planning % designing % programming % documentation % testing % reviewing % fixing % meeting % miscellaneous % TOTAL % Until Wednesday %