IS480 Team wiki: 2012T1 6-bit Project Management UT4

From IS480
Jump to navigation Jump to search
6-bit logo.png
6-bit's Chapalang! is a social utility that connects people with friends and new friends
by offering a place for exchanging ideas and information on its public domain.

Final Wikipage
Home Technical Overview Project Deliverables Project Management Learning Outcomes


Planned Schedule

6-bit ScheduleDiagramOverview.png

Meeting Minutes

Team Meeting Minutes

[|Meeting Minute 1] [|Meeting Minute 11] [|Meeting Minute 21]
[|Meeting Minute 2] [|Meeting Minute 12] [|Meeting Minute 22]
[|Meeting Minute 3] [|Meeting Minute 13] [|Meeting Minute 23]
[|Meeting Minute 4] [|Meeting Minute 14] [|Meeting Minute 24]
[|Meeting Minute 5] [|Meeting Minute 15] [|Meeting Minute 25]
[|Meeting Minute 6] [|Meeting Minute 16] [|Meeting Minute 26]
[|Meeting Minute 7] [|Meeting Minute 17] [|Meeting Minute 27]
[|Meeting Minute 8] [|Meeting Minute 18]
[|Meeting Minute 9] [|Meeting Minute 19]
[|Meeting Minute 10] [|Meeting Minute 20]

Supervisor Meeting Minutes

|Meeting Minute 1
|Meeting Minute 2
|Meeting Minute 3
|Meeting Minute 4
|Meeting Minute 5
|Meeting Minute 6
|Meeting Minute 7
|Meeting Minute 8
|Meeting Minute 9
|Meeting Minute 10
|Meeting Minute 11


Test Cases

|Test Cases

Test Plans

Test Plan 1 on 17 September 2012
Test Plan 2 on 28 September 2012
Test Plan 3 on 19 October 2012
Test Plan 4 on 4 November 2012

User Testing

User Testing 1 User Testing 2 User Testing 3 User Testing 4

User Testing 4


Test Description

The objective of User Test 4 is on scalability, performance and analytics testing of the system. This is a 2-part test session, firstly on scalability and performance which does not require physical testers, and secondly on inter-rater reliability which requires rating judges.

The coverage of the scalability and performance test is focused on the bottleneck functions, which are the discussion forums and marketplace. The terms “performance” and “scalability” are commonly used interchangeably, but the two are distinct: performance measures the speed with which a single request can be executed, while scalability measures the ability of a request to maintain its performance under increasing load.

Additionally, Inter-Rater Reliability Test is performed on the Personalized Dashboard to determine the concordance of the personalized results and actual personality of user stereotypes.

Testers Background

Scalability & Performance Testing

As the test does not require physical testers, the following appends the test environment.
6-bit ut4spec.png

Inter-Rater Reliability Test

Testers will assume the role of raters or judges for our Inter-Rater Reliability Test, represented by a total of 20 people with a 50-50 male is to female ratio. Testers are stratified from a diverse background, intended to represent personality stereotypes designed.

Personality stereotypes include characteristics such as gender, age group, education, personality traits, online activity, mobility and interested topics.

Test Groups

There is no test grouping employed in this test.

Test Procedures

Scalability & Performance Testing

The first part of the test is on scalability and performance testing. Chapalang Benchmark is configured to measure the time taken for each controller method before it starts and as soon as it ends. The results will be used to study the performance of the system and application at different scales of operations.

Additionally, custom application is used to perform a series of activities on a forum and marketplace, simulating an arbitrary number of concurrent users on the system, or the load.

Subsequently, we will study the benchmark timing data to understand the performance differences under different load.

Inter-Rater Reliability Test

An Inter-Rater Reliability (IRR) is the degree of agreement among raters. It gives a score of how much homogeneity or consensus there is in the ratings given by judges.

The first rater is the system itself, which will generate a list of 10 products and 10 discussion topics recommendations in descending order of relevance to a target user. Every recommendation is tied to a specific and distinct order number.

The second rater is a human tester, who will be provided with the same list of 10 products and 10 discussion topics generated by the system in relevance to him or herself. To mitigate the effects of Experimenter’s Bias, the order of each item is unordered and randomized without any intended logic. The second rater is expected to reorder the items according to his or her preferences in descending order.

Subsequently, we will make use of Spearman’s Rank Correlation Coefficient to understand the reliability of our personalized dashboard which features product and topic recommendations.

Test Instruction

Inter-Rater Reliability Test

This is a sample output of the first rater, for a product recommendation test.
6-bit ut4a.png
This is a sample input sheet for the second rater, on product recommendation test.
6-bit ut4b.png
In a descending order, 1 represents the most relevant item while 10 represents the least relevant item.

Test Results

Scalability & Performance Test

The terms “performance” and “scalability” are commonly used interchangeably, but the two are distinct: performance measures the speed with which a single request can be executed, while scalability measures the ability of a request to maintain its performance under increasing load.

  • (a) Identification of activities


  • (b) Identification of bottleneck

Based on the table above, we have identified that if a user experience is sequential, “Display single product” page has the longest elapsed time. At the same time, it has the longest elapsed time by itself, when compared to all the functions. Hence, we have identified this activity as the bottleneck.

  • (c) Measurement Performance

Referring to the same table above, we have determined the average of 5 tests on the “Display single product” activity for 1 concurrent user to have an elapsed time of 1.76997 seconds. Due to natural variation of the recorded timing, we will adopt 2 seconds as the performance upper limit.

  • (d) Scalability

We will now attempt to find out the maximum number of concurrent users that the system is able to support, given the performance of a single concurrent user. If we assume the performance upper limit to be 2 seconds, there is an estimated number of 16 concurrent users which has performed 2 seconds of lower.

  • (e) Results of up to 300 concurrent users

Performing further tests based on the markers of up to 300 concurrent users with 25-user intervals, for the purpose of intentionally simulating a load on the server to observe its deterioration in performance, if any.

Firstly, we have determined an arbitrary of acceptable performance of 3 seconds elapsed time for optimal user experience. Given this benchmark, we can observe that the system is capable of supporting up to 25 concurrent users.

Secondly, we have also observed peak deterioration in the trend line till approximately 75 users before the elapsed time for 100 concurrent users actually improved and reduced. The performance improved till approximately 200 concurrent users before it begins deterioration again. This is an unexpected and unusual observation for the team. With further consultation with technical experts, there are a variety of reasons which may lead to this anomaly. It could be due to simple outliers in our data, or it could be the use of swap memory on a Linux system (equivalent to pagination in Windows), and it could also be the nature of a switching between threading and non-threading operations of an apache web server.

Thirdly, the test crashed after approximately 260 concurrent connections. However, MySQL was still running but apache requires a reboot. Investigating into the log files, we understood that the MaxClient in our apache configuration is 256 and hence it is natural for it to fail. In addition, we found many forked and unreleased processes in the Linux server, which could have been further improved with system-level adjustments.

While the test shows that our system is capable of supporting 25 concurrent users within our acceptable performance, there are several variables in the circumstances that may limit the validity of this test result. Network performance is one key variable that can directly affect a user’s actual experience. Other limitations of the test include:

  • A standard MySQL is setup to handle 100 concurrent connections. For the purpose of test, we have lifted this limit.
  • Actual operations on the server consist of multiple concurrent connections on different pages, which make different SQL calls. The results above are limited because it tests on a single bottleneck controller, which locks a table and executes before it releases for the next process to perform. Hence, the elapsed time will be incurred exponentially which is rarely the case in real situations. As such, the above results may be pessimistic.
  • A server’s performance is also limited to a standard Apache non-threaded setup which serves 256 concurrent users using the mod_prefork module.

Even though the test result is not conclusive, it is sufficient for us to have a reasonable assumption that the server and application is capable of scaling up to 50 concurrent users while maintaining the same performance, and handling a load of approximately 25 concurrent users before suffering sub-optimal performance deterioration.

Inter-Rater Reliability Test

In order to evaluate the test results, we rely on the statistical model called Spearman’s Rank Correlation Coefficient (SRCC). The model is appended below:
In short, the SRCC model takes into account the rank rating from 2 different raters, represented by xi and yi respectively. In conventional Correlation of determination model, it takes in absolute data instead to find out statistical and data-driven correlation between 2 inputs.

However, we are interested in the consensus between human judgment on the data, therefore SRCC is a suitable model of analysis. The SRCC model assumes that the rating scale is ordinal, or basically serial scale of rating. This assumption is aligned with our 1 – 10 rating score which is incremental and serial. Additionally, the SRCC model considers only relative position of the ratings. For example, (1, 2, 1, 3) is considered perfectly correlated with (2, 3, 2, 4). This is acceptable in our test because each rating in our test is distinct and exhaustive, where no repeats or unused score is allowed.

The following is a sample of data tabulation in visual form.
With 6bituser-testing4di2.png found, we can add them to find 6bituser-testing4sumdi2.png 28. The value of n is 10. So these values can now be substituted back into the equation, we evaluate that p = 0.83.
Based on the nature of correlation coefficient value p, it has a range between -1 to 1. Here are some of the characteristics of the p value.

  • A negative number suggests negative relationship,
  • A positive number suggests positive relationship,
  • A size of a positive or negative number closer to 1 or -1 suggests strength of relationship,
  • and A p value of 0 suggests an absolute lack of relationship in the input attributes.

It should be noted that if there is a strongly negative correlation, it may suggest a reversal in the order of recommendations in our system may eventually become an ideal model.
The accuracy sentimental analysis system is, in principle, how well it agrees with human judgment, despite the fact that the applied accuracy in our test is to ensure an optimal user experience and optimal sales exposure.
However, the limitation of the model is that human raters typically agree about 70% of the time and even if a system is 100% accurate by assumption, humans will still disagree about 30% of the time. Hence, for the purpose of our study, it may be suggested that an application with 100% human agreeableness can only be statistically justified to be 70% accurate and more sophisticated methods should be used to endorse the remaining 30% of accuracy.

After conducting the IRR Test, the results are tabulated and appended as follows.
Tester IDs that begins with M denotes male testers, while F denotes Female testers. The categorization of results will help us understand a basic level of stereotyping accuracy by gender. If need it, the results can be further drilled down to represent a more specific personality stereotype.

Summarising the test results tabulated above, the average for median p-value for male is 0.8695 and median p-value for female is 0.8675. Based on the median values, there is no significant difference in accuracy for male and females. In addition, it is satisfactorily justified that there is a strong positive correlation between the recommendations of our system and the preferences of the testers, a sample from our potential users, based on their consensus.  


6-bit schedule.png

Schedule Metric

Every iteration, schedule metric values are calculated to understand the project progress. They are broadly categorized into 5 different groups, where different action plans will apply. The acceptable range of value is within 90% to 110%, offering some buffer for natural inaccuracies between forecasting and execution.

Total Schedule Metric Value = Planned no. of days taken (P) / Actual no. of Days Assigned (A) x 100%

6-bit schedulemetric.png

Bug Metric


6-bit BugMetric.png 6-bit BugLog.png

Bug Log: |Click Here

Bug logging for Chapalang! takes the direction of being practical and easily monitored from both macro and micro perspectives. Whenever a bug is found, a new row is entered with the following data:

  • Index number
  • Bug description
  • Found by
  • Found date
  • Expected solve-by date
  • Bug severity
  • Status
  • Owner of the function
  • Fixed date
  • Closed by (Tester)
  • Close date
  • Additional comments


Bugs are classified into 3 different categories of complexity, easy, moderate and hard. Each category is assigned points of 1, 5 and 10 respectively, lower is better.

Total Points for Each Iteration = Σ Points of the Bugs in each iteration

6-bit BugMetricFormula.png

After assigning each bug with points associated by its complexity, we will track the total bug scores at the end of each week before deciding if there should be any actions to be taken. The following is an action plan for our bug metric:

6-bit BugMetricFormula2.png

Risk & Mitigation

6-bit RiskDiagram.png