Asg2 - Teamwork - Version Control - Static Review Value: 40% Due date: 19-Aug-2016 Return date: 12-Sep-2016 Submission method options Alternative submission method Task Conceptually, Assignment 2 is fairly straightforward: As a team, carry out a development task, then review and combine the contribution of each team member into a completed whole. In practice there are a lot of steps in this process. On a weekly basis: 1. Carry out your assigned development tasks using best practice version control within your individual branch. 2. Communicate as necessary and desirable with your team members. 3. Upload whatever you have completed to version control as evidence for evaluation of work items. 4. Attend the weekly iteration planning and assessment meeting. At the meeting present whatever you have done in the preceding week and evaluate it against the objective completion criteria specified in the iteration plan. 5. Create a plan for the next iteration, setting out individual tasks and objective completion criteria for the coming week. Divide work equitably between team members. Finally: 1. When you have completed your development task, conduct a static code review. You will need to participate in code reviews for the other members in your team as well. 2. Merge your individually developed code with the code developed by other members of your team in the team version control repository. 3. Write a 'phase status assessment' in which you address the following questions: 1. Did the team achieve the development task set for the assignment? What issues arose in achieving the final result How did the team manage those issues? 2. What issues regarding communication did the team encounter? How were these issues addressed? 3. What issues regarding version control did the team encounter? How were these issues addressed? 4. What issues regarding the static code review did the team encounter? How were these issues addressed? Note: This assignment depends critically on successful completion of Assignment 1. Because of the dependencies between students in the current assignment, Assignment 1 is marked as satisfactory/unsatisfactory and you can fail the subject if you receive an unsatisfactory assessment for that task. Note: You are expected to establish and use a push communication mechanism to facilitate rapid and responsive communication between team members outside of the scheduled online meetings. Further Note: It is NOT THE CASE that more team members means less work or that fewer team members means more work. The coding task in this assignment is relatively trivial. The bulk of the work in the assignment is in coordinating and conducting the static reviews. Fewer team members might mean more coding but the coordination and review tasks are greatly simplified. More team members might mean less code work, but the coordination and review tasks are significantly more complicated. In the end, it comes out about even. Tasks 1. Teamwork (40 marks) This part of the assignment monitors and measures your individual performance as a team member. It assumes that you have successfully completed the team management aspects of Assignment 1. Distributed teamwork is difficult and inconvenient, and the essence of teamwork is compromise. You must make yourself available to participate in team meetings once a week at a time that is generally acceptable to a majority of team members, even if it is somewhat inconvenient to yourself. Negotiation is acceptable. Rigid insistence on personal preference is not. Make it happen. Use weekends if necessary. If you can't make it to a generally favoured time be prepared to explain your objections with substantive reasons. Reasons such as favourite televisions shows, or preferring to go out at that time are not acceptable. Note: It is critical for this part of the assignment that weekly tasks and objective completion criteria are set at the planning and evaluation meeting that marks the end of each iteration. It is also critical that evidence to support any claim of work-item completion is placed under version control. If work items and completion criteria are not recorded, or evidence to support claims of work item completion is not placed under version control, then those work items will be considered not have been undertaken or completed. To be explicit: it is not sufficient to just do the work, it must be seen to be done. The work must be planned, criteria for its completion set, the work evaluated against those criteria, and all of this must be recorded and evidenced in the iteration evaluation and in version control. On a weekly basis: 1. Attend an iteration planning and evaluation meeting 1. Record attendance at the meeting, and any reasons provided for non-attendance. 2. Review work items scheduled to have been completed over the previous week. Record the completion status and any explanatory information for non-completion in the in an iteration assessment report. 3. Discuss and plan work items to be completed in the following week. Record the work items identified, together with clear and quantitative completion criteria in an iteration planning report. Also record who is assigned to complete which work item. 4. Upload the meeting minutes and the iteration planning and assessment reports to your team wiki. 2. Carry out your assigned work items as assigned at the team meeting in the scheduled timeframe. 3. Communicate as necessary and desirable with your teammates using your selected push communication mechanism to coordinate your development activities Finally: 4. Participate effectively in at least 3 static code reviews, taking on each of the roles of mediator, reviewer, and author at least once. IE rotate roles between team members in each review. 5. Merge your reviewed code with the main branch of the team's code repository. 2. Version Control (30 marks) 1. As a team, download the files provided for the assignment from the subject website, and establish a code baseline under version control. Use github or any other free publically accessible GIT repository. Make sure every member of the team has read/write access. Grant the lecturer full team member access, and post the URL in the team wiki. Note: if you are concerned about public access to your repository, there is a git server based on gitlab which supports private repositories available at the following URL: http://gitlab.csu.edu.au 2. As an individual, create a branch for your own line of code development. Grant the lecturer full access and post the URL for your individual branch in the team wiki. 3. As an individual, carry out the development tasks assigned to you by the group, committing your work to version control following best practice guidelines. 4. As an individual, when you have finished individual development, at the beginning of the static code review process, when you are notified by the review mediator, create a 'pull request' (merge request on gitlab) to merge your code with the team's central development branch. 5. As a team, conduct a formal code review of the proposed changes a detailed below in Task 3, and ensure the proposed changes meet with code quality guidelines. 6. As an individual, following the static code review process detailed as Task 3 of this assignment, merge your code with the main line of development. Ensure that the main line of development functions correctly following your merge. Correct operation of the main line of development must be verified after the merge by the mediator for the static review. 3. Static Code Review (30 marks) 1. As a team, organise a set of tool assisted static code reviews to ensure each team member's code development is acceptable before allowing a merge with the main line of development. Carry out the code review for each team member's development. Once the mediator has established that all issues have been satisfactorily addressed, the author must perform a merge with the main line of development. The mediator for the review must verify the success of the merge and inform the next scheduled review's mediator that the main line of development is ready. You will be supplied with a URL and a login to access an online code review tool during the first few weeks of semester. A HowTo video demonstrating how to submit code for review will also be made available. It is mandatory to use the supplied code review tool, since this provides the audit trail necessary to assess this section of the assignment. The entire team should participate in each review. Each review should consist of at least three roles: a mediator/organizer, a reviewer, and an author. If there are more than 3 team members, enact additional review roles. The code to be reviewed is all code developed by the author, including any changes made to the mainline of development in order to resolve conflicts during the merge. IE the code to be reviewed is the final code that will be incorporated without change in the main line of development. By far the best and safest way to perform a successive merges is to insist that they are coordinated and sequential. It is a good idea to organize reviews and update/merges in order from least experienced to most experienced programmer Clearly, combining the work of multiple developers is a complicated, brittle process that requires a great deal of coordination. It is not just an individual's effort that needs review, but how that effort fits together with previously integrated work. This is why reviews and merges have to be sequential. You may find that it greatly facilitates a rapid and problem free formal review to conduct informal peer reviews (over-the-shoulder reviews) during development. Given the multiple sequential dependencies, it is critical that mediators coordinate their reviews closely, and it is also critical that early reviews and merges complete in a timely fashion. Do not underestimate the difficulty and time required to review and integrate three or more separate developer's code contributions. The submit/review/rework/approve cycle can take several days, so the entire integration process can potentially take well over a week. Aim to complete individual development well before the due date for the assignment (at least a week) in order to leave sufficient time to complete the review process properly. Remember, the focus in this assignment is on teamwork, correct use of version control, and correct carrying out of the static code review process – not on the actual code development, which is quite trivial. Code Review Roles Mediator The mediator's role is to organise and facilitate the code review. It is the code review mediator's responsibility to ensure that the author delivers code for review by the time the review is scheduled, and that the reviewer carries out the review within the scheduled period. It is also the mediator's role to ensure that any follow up work required is carried out in a timely manner. It is the mediator's role to clarify any misunderstandings and mediate any disagreements between reviewers and author, or between reviewers. It is the mediator's responsibility to ensure that the main line of development is working as expected before notifying the author to update their branch with the results of the latest merge prior to the static code review process. It is also the mediator's responsibility to verify that the main line of code is working properly after the author has carried out the final merge. Reviewer The reviewer's role is to review submitted code and ensure that it meets code quality guidelines. It is the reviewer's responsibility to review the submitted code and ensure it meets the required standards, within the scheduled period. The reviewer must record every instance of non-compliance with standards and all detected bugs. A copy of relevant coding standards will be available on the subject web site. It is also the reviewer's responsibility to promptly review any rework submitted in response to one of their comments, and to notify the mediator when rework has been approved. Author The author's role is to produce code to the required standards and to carry out any rework required. It is the author's responsibility to provide the required code at the required standard by the time the review is scheduled. It is also the author's responsibility to carry out any follow up work needed to address every recorded issues and submit the revised code to the mediator's satisfaction in a timely manner. (Timely as defined by the team, not the author) Most importantly it is the author's responsibility to merge approved code with the team repository and ensure that the main line of development works as it should following the merge. Rationale This assignment is motivated by the following subject learning outcomes: • demonstrate the ability to work effectively in a team environment (Learning Outcome 1); • apply knowledge and skills to effectively utilize version control (Learning Outcome 2); • identify the purpose and limitations of software testing (Learning Outcome 4); • design and implement an appropriate suite of software tests to support the complete system development life cycle (Learning Outcome 5); The intent To demonstrate and apply taught concepts, and exercise skills related to teamwork, version control, and static code review. Marking criteria Teamwork - (40 marks) Criteria High Distinction Distinction Credit Pass Fail How well did the student demonstrate the ability to work effectively in a team environment? Attended and participated effectively in all team meetings as evidenced in team meeting minutes. Communicated extremely responsively (generally within a few (<4) hours) as evidenced by the push messaging mechanism logs. Planned work items completely specific and supported by completely specific quantitative completion criteria as evidenced by the iteration plans. Planned work items represent an ambitious (> 8 hours) workload as evidenced by the iteration plans. Workload is equitable. All planned work items completed on time as evidenced in the iteration evaluations. All planned work items completed to an extremely high standard as evidenced in the iteration evaluations. Targets and evaluations substantiated with comprehensive evidence under version control Participated highly effectively and extremely responsively as mediator, reviewer, and author during static code review as evidenced by the code review tool logs. Attended and participated effectively in nearly all team meetings as evidenced in team meeting minutes. Communicated responsively (generally within several (<12) hours) as evidenced by the push messaging mechanism logs. Planned work items specific and supported by quantitative completion criteria as evidenced by the iteration plans. Planned work items represent a substantial (> 6 hours) workload as evidenced by the iteration plans. Workload is reasonably equitable. Nearly all planned work items completed on time as evidenced in the iteration evaluations. Nearly all planned work items completed to a high standard as evidenced in the iteration evaluations. Targets and evaluations substantiated with solid evidence under version control Participated effectively and responsively as mediator, reviewer, and author during static code review as evidenced by the code review tool logs. Attended and participated effectively in most team meetings as evidenced in team meeting minutes. Communicated fairly responsively (generally within a day) as evidenced by the push messaging mechanism logs. Planned work items fairly generalised and supported by fairly generalised completion criteria as evidenced by the iteration plans. Planned work items represent a moderate (> 4 hours) workload as evidenced by the iteration plans. Workload may be slightly inequitable. Most planned work items completed on time as evidenced in the iteration evaluations. Most planned work items completed a good standard as evidenced in the iteration evaluations. Targets and evaluations supported with reasonable evidence under version control Participated fairly effectively and fairly responsively as mediator, reviewer, and author during static code review as evidenced by the code review tool logs. Attended and participated effectively in some team meetings as evidenced in team meeting minutes. Communicated adequately but slowly (generally within a day or two) as evidenced by the push messaging mechanism logs. Planned work items highly generalised and supported by highly quantitative completion criteria as evidenced by the iteration plans. Planned work items represent a fairly light (> 2 hours) workload as evidenced by the iteration plans. Workload may be fairly inequitable. Some planned work items completed on time as evidenced in the iteration evaluations. Most planned work items completed a reasonable standard as evidenced in the iteration evaluations. Targets and evaluations supported with adequate evidence under version control Participated adequately but slowly as mediator, reviewer, and author during static code review as evidenced by the code review tool logs. Attended and participated effectively in very few or no team meetings as evidenced in team meeting minutes. Communicated inadequately (generally took longer than a couple of days) as evidenced by the push messaging mechanism logs. Planned work items either not specified, or extremely vague. Not supported by any completion criteria or completion criteria extremely vague. Planned work items represent an inadequate (< 2 hours) workload as evidenced by the iteration plans. Workload is inequitable. Very few or no planned work items completed on time as evidenced in the iteration evaluations. Very few or no planned work items to a reasonable standard as evidenced in the iteration evaluations. Targets and evaluations not supported with evidence under version control Participated inadequately and not in a timely manner as mediator, reviewer, and author during static code review as evidenced by the code review tool logs. Version Control (30 marks) Criteria High Distinction Distinction Credit Pass Fail How well does the student apply knowledge and skills to effectively utilize version control? Complete comprehension and application of the concepts and practices explained in git-flow. Many commits, applied whenever it became desirable not to lose completed work (ie ~ 2 hours) Comments thorough and understandable. Many pushes to online repository, coordinated with local commits. Final merge successful. Nearly complete comprehension and application of the concepts and practices explained in git-flow. Many commits, applied when significant chunks of work completed (ie 2-4 hours) Comments brief but understandable. Several pushes to online repository, coordinated with major advances in functionality. Final merge successful, some rework. Sound comprehension and application of the concepts and practices explained in git-flow. Few commits, applied when major chunks of work completed (ie >6-8 hours) Comments brief and understandable only in context. Few pushes to online repository. Final merge successful, considerable rework. Adequate comprehension and application of the concepts and practices explained in git-flow. Very few commits, applied at long intervals (> 1 week). Comments uninformative One push to online repository at the end of development. Required intervention from other team members to successfully complete merge. Inadequate comprehension and application of the concepts and practices explained in git-flow. All and any updates committed once at the very end. No comments. No pushes to central repository. Broke main line of development, and left it like that. Static Code Review (30 marks) Criteria High Distinction Distinction Credit Pass Fail How well did the student work effectively as part of a team to address software testing in the context of a static code review? As author: Code ready for review early. Code quality extremely high. Responded extremely responsively to reviewer's comments. Completed work without prompting. As reviewer: Carried out review very quickly. No errors or inconsistencies unremarked. As mediator: Smoothly and politely expedited completion of code review. Proactively liaised with next review to inform of progress and completion. As author: Code ready for review on time. Code quality very good. Responded responsively to reviewer's comments. Completed work without prompting. As reviewer: Carried out review promptly. Very few errors and inconsistencies unremarked. As mediator: Actively tracked of progress of review, and coordinated/mediated reviewer and author activities. Actively liaised with next review to inform of progress and completion. As author: Code nearly ready for review on time. Code quality acceptable. Responded fairly responsively to reviewer's comments. Completed work with some prompting. As reviewer: Carried out review on time. Several errors and inconsistencies unremarked. As mediator: Notified author and reviewer that review should commence in timely manner. Notified next review's mediator when review complete. As author: Did not provide code on time. Code quality poor. Responded adequately but slowly to reviewer's comments. Had to be chased to complete work. As reviewer: Slow carrying out review. Many errors and inconsistencies unremarked. As mediator: Slow to notify author and reviewer that review should commence. Slow to notify next review's mediator when review complete. As author: Did not provide code on time. Code quality very poor. Responded inadequately to reviewer's comments. Did not complete work. As reviewer: Did not carry out review on time. Few or no errors or inconsistencies remarked. As mediator: Failed to notify author and reviewer that review should commence. Failed to notify next review's mediator when review complete. Presentation There are three aspects of presentation for this assignment: 1. The team wiki. This should contain: 1. Your team charter. 2. The URL for the combined team repository (the main line of development) 3. The URLs for the individual team members development branches. 4. The URL to the push communication mechanism you select. 5. The minutes for each of the weekly team meetings. 6. The weekly iteration planning and assessment reports. 2. The combined team version control repository. This should initially contain the provided code baseline, and eventually contain the results of merging each team members separate development. 3. Your individual development repository. This should initially contain the code baseline as branched from the team repository. Eventually it should contain a record of the successive commits you make during development, and finally the results of updating your branch from the central repository prior to code review and merge.